Application servers provide a comprehensive platform for developing, deploying, and integrating enterprise applications. They supply the presentation, business and information access logic, security and management services, as well as the underlying infrastructure needed for a wide variety of software applications. Typically, an application server supports many types of clients, such as web browsers and wireless devices, as well as different operating systems, databases, message queues and legacy systems.
In recent years, a standard has emerged for modularizing the deployment of various software components, including application servers. This standard has been proposed by the OSGi alliance (formerly known as the Open Services Gateway Initiative) and it involves the process of breaking up and packaging the server into multiple bundles, which can be deployed onto different physical machines, upgraded, started and stopped remotely, and the like. Application servers usually include a number of components that can be broken up in this manner, including different factories used for creating objects (e.g. instantiating classes, etc.).
A factory can be thought of as an object used to create other objects in a consistent manner. The factory pattern thus solves the problem of disassociating the user from the creational details of objects. It is generally undesirable to allow each developer to create objects ad hoc, due to the possible lack of consistency among them. As a solution, instead of manually creating each object, the application can invoke a factory that will carry out the steps needed to create the object.
However, the standard software factory pattern does not address the relationships between multiple factories. This becomes significant when more than one factory can be used to carry out the same job and a factory needs to be chosen before using it to create objects. Some factories are more specialized forms of other factories and thus frequently multiple factories can be used to create the same object. This can be thought of as a problem of overlapping factories since there is an overlap in the set of situations that they can handle. In order to ensure consistency in functionality, it is important to ensure that factories are selected in a uniform and consistent way.
In the past, one way to select factories has been by using the order of factory registration. Factories are usually registered with the application server in a particular order during server startup. Thus, when two or more factories are capable of creating a requested object, the factory that was registered first with the application server would be selected to carry out the creation. However, as a result of OSGi and server modularization, the order of factory registration may not necessarily be consistent across different server startups. Because OSGi bundles can be deployed in different orders or combinations, it is no longer desirable to use factory registration to set priority for selecting the factory used to create a particular object. For example, if factory registration order were to be used, different factories could end up responsible for creating a particular object depending on the order in which the server bundles were started up. This can lead to inconsistencies in functionality and other issues. As such, an alternative process for selecting factories is desirable, one which enables consistent functionality among objects regardless of order of startup or registration. Applicants have identified the foregoing as well as other needs that currently exist in the art in coming to conceive the subject matter of the present disclosure.